home *** CD-ROM | disk | FTP | other *** search
/ CD ROM Paradise Collection 4 / CD ROM Paradise Collection 4 1995 Nov.iso / music / miditime.zip / MIDITIME.DOC
Text File  |  1994-10-29  |  33KB  |  1,050 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7.  
  8.  
  9.  
  10.  
  11.  
  12.  
  13.  
  14.  
  15.  
  16.  
  17.  
  18.  
  19.  
  20.  
  21.  
  22.  
  23.  
  24.  
  25.  
  26.  
  27.  
  28.  
  29.  
  30.  
  31.  
  32.  
  33.  
  34.  
  35.  
  36. MIDI Time Code and Cueing
  37.  
  38. Detailed Specification
  39.  
  40. (Supplement to MIDI 1.0)
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.  
  59.  
  60.  
  61.  
  62.  
  63.  
  64.  
  65.  
  66.  
  67.  
  68.  
  69.  
  70.  
  71.  
  72.  
  73.  
  74.  
  75.  
  76.  
  77.  
  78. 12 February 1987
  79.  
  80. Justification For  MIDI Time Code and Cueing
  81.  
  82.  
  83.  
  84.      The merit of implementing the MIDI Time Code proposal within the current
  85. MIDI specification is as follows:
  86.  
  87.  
  88.  
  89.      SMPTE has become the de facto  timing reference standard in the
  90. professional audio world and in almost the entire video world.  SMPTE is also
  91. seeing more and more use in the semi-professional audio area.  We hope to
  92. combine this universal timing reference, SMPTE, with the de facto  standard
  93. for controlling musical equipment, MIDI.
  94.  
  95.  
  96.  
  97.      Encoding SMPTE over MIDI allows a person to work with one timing
  98. reference throughout the entire system.  For example, studio engineers are
  99. more familiar with the idea of telling a multitrack recorder to punch in and
  100. out of record mode at specific SMPTE times, as opposed to a specific beat in a
  101. specific bar.  To force a musician or studio engineer to convert back and
  102. forth between a SMPTE time and a specific bar number is tedious and should not
  103. be necessary (one would have to take into account tempo and tempo changes,
  104. etc.).
  105.  
  106.  
  107.  
  108.      Also, some operations are referenced only as SMPTE times, as opposed to
  109. beats in a bar.  For example, creating audio and sound effects for video
  110. requires that certain sounds and sequences be played at specific SMPTE times.
  111. There is no other easy way to do this with Song Position Pointers, etc., and
  112. even if there was, it would be an unnatural way for a video or recording
  113. engineer to work.
  114.  
  115.  
  116.      MIDI Time Code is an absolute timing reference, whereas MIDI Clock and
  117. Song Position Pointer are relative timing references.  In virtually all audio
  118. for film/video work, SMPTE is already being used as the main time base, and
  119. any musical passages which need to be recorded are usually done by getting a
  120. MIDI-based sequencer to start at a pre-determined SMPTE time code.  In most
  121. cases, though, it is SMPTE which is the Master timing reference being used.
  122. In order for MIDI-based devices to operate on an absolute time code which is
  123. independent of tempo, MIDI Time Code must be used. Existing devices merely
  124. translate SMPTE into MIDI Clocks and Song Position Pointers based upon a given
  125. tempo.  This is not absolute time, but relative time, and all of the SMPTE cue
  126. points will change if the tempo changes.  The majority of sound effects work
  127. for film and video does not involve musical passages with tempos, rather it
  128. involves individual sound effect "events" which must occur at specific,
  129. absolute times, not relative to any "tempo".
  130.  
  131.  
  132.  
  133. MIDI Time Code System Components
  134.  
  135.  
  136.  
  137. SMPTE to MTC Converter
  138.  
  139.  
  140.  
  141.      This box would either convert longitudinal (audio-type) or vertical
  142. (video-type) SMPTE time code from a master timing device into MTC. The
  143. function could be integrated into video tape recorders (VTRs) or
  144. syncronization units that control audio tape recorders (ATRs). Alternately, a
  145. stand-alone box would do the conversion, or simply generate MTC directly.
  146. Note that conversion from MTC to SMPTE time code is not envisioned, as it is
  147. of little practical value.
  148.  
  149.  
  150.  
  151. Cue List Manager
  152.  
  153.  
  154.  
  155.      This would be a device or computer program that would maintain a cue list
  156. of desired events, and send the list to the slaves. For performance, the
  157. manager might pass the Time Code from the SMPTE-MTC converter through to the
  158. slaves, or, in a stand-alone system it might generate Time Code itself. This
  159. "central controller" would presumably also contain all library functions for
  160. downloading sound programs, samples, sequences, patterns, and so on, to the
  161. slaves. A Cue List Manager would pre-load intelligent MTC peripherals (see
  162. below) with this data.
  163.  
  164.  
  165.  
  166. MTC Sequencer
  167.  
  168.  
  169.  
  170.      To control existing equipment or any device which does not recognize MTC
  171. in an MTC system, this device would be needed. It would receive the cue list
  172. from the manager, and convert the cues into normal MIDI commands.   At the
  173. specified SMPTE times, the sequencer would then send the MIDI commands to the
  174. specific devices. For example, for existing MIDI equipment it might provide
  175. MIDI messages such as Note On, Note Off, Song Select, Start, Stop, Program
  176. Changes, etc. Non-MIDI equipment (such as CD players, mixing consoles,
  177. lighting, sound effects cartridge units and ATRs) may also be controlled if
  178. such a device had relay controls.
  179.  
  180.  
  181.  
  182. Intelligent MTC Peripheral
  183.  
  184.  
  185.  
  186.      In this category belong devices capable of receiving an MTC Cue List from
  187. the manager, and triggering themselves appropriately when the correct Time
  188. Code (SMPTE or MIDI) has been received.  Above this minimum, the device might
  189. be able to change its programming in response to the Cue List, or prepare
  190. itself for ensuing events.
  191.  
  192.  
  193.  
  194.      For example, an intelligent MTC-equipped analog multitrack tape machine
  195. might read in a list of punch in/punch out cues from the Cue List Manager, and
  196. then alter then to internally compensate for its bias current rise and fall
  197. times. A sampling-based sound effects device might preload samples from its
  198. own disk drive into a RAM buffer, in anticipation of needing them for cues
  199. later on in the cue list.
  200.  
  201.  
  202.  
  203.      It should be mentioned that while these functions are separately
  204. described, actual devices may incorporate a mixture of these functions, suited
  205. to specific applications in their market.
  206.  
  207.  
  208. A MIDI Time Code System
  209.  
  210.  
  211.  
  212.      The MIDI Time Code format contains two parts: Time Code and Set Up. Time
  213. Code is relatively straightforward: hours, minutes, seconds and frame numbers
  214. (approximately 1/30 of a second) are encoded and distributed throughout the
  215. MIDI system so that all the units know exactly what time it is.
  216.  
  217.  
  218.  
  219.      Set Up, however, is where MTC gains its power. It is a format for
  220. informing MIDI devices of events to be performed at specific times.
  221. Ultimately, this aspect of MTC will lead to the creation of an entirely new
  222. class of production equipment. Before getting into the nuts and bolts of the
  223. spec itself, let's talk about some of the uses and features of forthcoming
  224. devices that have been envisioned.
  225.  
  226.  
  227.  
  228.      Set Up begins with the concept of a cue list. In video editing, for
  229. example, it is customary to transfer the video master source tapes, which may
  230. be on expensive, two-inch recorders, to less-expensive recorders. The editing
  231. team then works over this copy, making a list of all the segments that they
  232. want to piece together as they are defined by their SMPTE times.
  233.  
  234.  
  235.  
  236.      For example, the first scene starts at time A and ends at time B, the
  237. next scene starts at time C and ends at time D. A third scene may even lie
  238. between the first two. When done, they feed this cue list time information
  239. into the editing system of the master recorder(s) or just give the cue list to
  240. an editor who does the work manually. The editing system or editor then
  241. locates the desired segments and assembles them in the proper sequence.
  242.  
  243.  
  244.  
  245.      Now suppose that instead of one or two video recorders, we have twenty
  246. devices that will play a part in our audio/video or film production:  special
  247. effects generators for fades and superimpositions, additional decks with
  248. background scenery, live cameras, MIDI sequencers, drum machines,
  249. synthesizers, samplers, DDLs, soundtrack decks, CDs, effects devices, and so
  250. on. As it stands now, each of these devices must be handled more or less
  251. separately, with painstaking and time-consuming assembly editing or multitrack
  252. overdubs. And when a change in the program occurs (which always happens),
  253. anywhere from just a few items to the whole system may need to be reprogrammed
  254. by hand.
  255.  
  256.  
  257.  
  258.      This is where MIDI Time Code comes in. It can potentially control all of
  259. these individual production elements so that they function together from a
  260. single cue list. The master controller which would handle this function is
  261. described as a Cue List Manager. On such a console, you would list what you
  262. want each device to do, and when to do it. The manager would then send the cue
  263. list to the various machines via the MTC Set Up protocol. Each unit would then
  264. react as programmed when the designated MIDI Time Code (or conventional SMPTE
  265. Time Code) appears. Changes? No problem. Simply edit the cue list using simple
  266. word-processing functions, then run the tape again.
  267.  
  268.  
  269.      MTC thus integrates into a manageable system all of the diverse tools at
  270. our disposal. It would drastically reduce the time, money and frustration
  271. needed to produce a film or video.
  272.  
  273.  
  274.      Having covered the basic aspects of a MIDI Time Code system, as well as
  275. examples of how an overall system might function, we will now take a look at
  276. the actual MIDI specification itself.
  277.  
  278.  
  279. MIDI Time Code
  280.  
  281.  
  282.  
  283.      For device synchronization, MIDI Time Code uses two basic types of
  284. messages, described as Quarter Frame and Full. There is also a third, optional
  285. message for encoding SMPTE user bits.
  286.  
  287.  
  288. Quarter Frame Messages
  289.  
  290.  
  291.  
  292.      Quarter Frame messages are used only while the system is running. They
  293. are rather like the PPQN or MIDI clocks to which we are accustomed. But there
  294. are several important ways in which Quarter Frame messages differ from the
  295. other systems.
  296.  
  297.  
  298.      As their name implies, they have fine resolution. If we assume 30 frames
  299. per second, there will be 120 Quarter Frame messages per second. This
  300. corresponds to a maximum latency  of 8.3 milliseconds (at 30 frames per
  301. second), with accuracy greater than this possible within the specific device
  302. (which may interpolate inbetween quarter frames to "bit" resolution).  Quarter
  303. Frame messages serve a dual purpose: besides providing the basic timing pulse
  304. for the system, each message contains a unique nibble (four bits) defining a
  305. digit of a specific field of the current SMPTE time.
  306.  
  307.  
  308.  
  309.      Quarter frames messages should be thought of as groups of eight messages.
  310. One of these groups encodes the SMPTE time in hours, minutes, seconds, and
  311. frames. Since it takes eight quarter frames for a complete time code message,
  312. the complete SMPTE time is updated every two frames.  Each quarter frame
  313. message contains two bytes. The first byte is F1,  the Quarter Frame System
  314. Common byte. The second byte contains a nibble that represents the message
  315. number (0 through 7), and a nibble for one of the digits of a time field
  316. (hours, minutes, seconds or frames).
  317.  
  318.  
  319.  
  320.  
  321.  
  322. Quarter Frame Messages (2 bytes):
  323.  
  324.  
  325.  
  326.      F1  <message>
  327.  
  328.  
  329.  
  330.           F1 = Currently unused and undefined System Common status byte
  331.  
  332.           <message> = 0nnn dddd
  333.  
  334.  
  335.  
  336.                dddd = 4 bits of binary data for this Message Type
  337.  
  338.                nnn =  Message Type:
  339.  
  340.                     0 = Frame count LS nibble
  341.  
  342.                     1 = Frame count MS nibble
  343.  
  344.                     2 = Seconds count LS nibble
  345.  
  346.                     3 = Seconds count MS nibble
  347.  
  348.                     4 = Minutes count LS nibble
  349.  
  350.                     5 = Minutes count MS nibble
  351.  
  352.                     6 = Hours count LS nibble
  353.  
  354.                     7 = Hours count MS nibble and SMPTE Type
  355.  
  356.  
  357.  
  358.      After both the MS nibble and the LS nibble of the above counts are
  359. assembled, their bit fields are assigned as follows:
  360.  
  361.  
  362.  
  363. FRAME COUNT:  xxx yyyyy
  364.  
  365.  
  366.  
  367.                xxx = undefined and reserved for future use.  Transmitter
  368.  
  369.                     must set these bits to 0 and receiver should ignore!
  370.  
  371.                yyyyy = Frame number (0-29)
  372.  
  373.  
  374.  
  375. SECONDS COUNT:  xx yyyyyy
  376.  
  377.  
  378.  
  379.                xx = undefined and reserved for future use.  Transmitter
  380.  
  381.                      must set these bits to 0 and receiver should ignore!
  382.  
  383.                yyyyyy = Seconds Count  (0-59)
  384.  
  385.  
  386.  
  387. MINUTES COUNT:  xx yyyyyy
  388.  
  389.  
  390.  
  391.                xx = undefined and reserved for future use.  Transmitter
  392.  
  393.                      must set these bits to 0 and receiver should ignore!
  394.  
  395.                yyyyyy = Minutes Count  (0-59)
  396.  
  397.  
  398.  
  399. HOURS COUNT:  x yy zzzzz
  400.  
  401.  
  402.  
  403.                x = undefined and reserved for future use.  Transmitter
  404.  
  405.                      must set this bit to 0 and receiver should ignore!
  406.  
  407.  
  408.  
  409.                yy = Time Code Type:
  410.  
  411.                     0 = 24 Frames/Second
  412.  
  413.                     1 = 25 Frames/Second
  414.  
  415.                     2 = 30 Frames/Second (Drop-Frame)
  416.  
  417.                     3 = 30 Frames/Second (Non-Drop)
  418.  
  419.  
  420.  
  421.                zzzzz = Hours Count  (0-23)
  422.  
  423.  
  424. Quarter Frame Message Implementation
  425.  
  426.  
  427.  
  428.      When time code is running in the forward direction, the device producing
  429. the MIDI Time Code will send Quarter Frame messages at quarter frame intervals
  430. in the following order:
  431.  
  432.  
  433.  
  434.                     F1 0X
  435.  
  436.                     F1 1X
  437.  
  438.                     F1 2X
  439.  
  440.                     F1 3X
  441.  
  442.                     F1 4X
  443.  
  444.                     F1 5X
  445.  
  446.                     F1 6X
  447.  
  448.                     F1 7X
  449.  
  450.  
  451.  
  452. after which the sequence repeats itself, at a rate of one complete 8-message
  453. sequence every 2 frames (8 quarter frames).  When time code is running in
  454. reverse, the quarter frame messages are sent in reverse order, starting with
  455. F1 7X and ending with F1 0X.  Again, at least 8 quarter frame messages must be
  456. sent.  The arrival of the F1 0X and F1 4X messages always denote frame
  457. boundaries.
  458.  
  459.  
  460.  
  461.      Since 8 quarter frame messages are required to definitely establish the
  462. actual SMPTE time, timing lock cannot be achieved until the reader has read a
  463. full sequence of 8 messages, from first message to last.  This will take from
  464. 2 to 4 frames to do, depending on when the reader comes on line.
  465.  
  466.  
  467.      During fast forward, rewind or shuttle modes, the time code generator
  468. should stop sending quarter frame messages, and just send a Full Message once
  469. the final destination has been reached.  The generator can then pause for any
  470. devices to shuttle to that point, and resume by sending quarter frame messages
  471. when play mode is resumed.  Time is considered to be "running" upon receipt of
  472. the first quarter frame message after a Full Message.
  473.  
  474.  
  475.      Do not send quarter frame messages continuously in a shuttle mode at high
  476. speed, since this unnecessarily clogs the MIDI data lines.  If you must
  477. periodically update a device's time code during a long shuttle, then send a
  478. Full Message every so often.
  479.  
  480.  
  481.      The quarter frame message F1 0X (Frame Count LS nibble) must be sent on a
  482. frame boundary.  The frame number indicated by the frame count is the number
  483. of the frame which starts on that boundary.  This follows the same convention
  484. as normal SMPTE longitudinal time code, where bit 00 of the 80-bit message
  485. arrives at the precise time that the frame it represents is actually starting.
  486. The SMPTE time will be incremented by 2 frames for each 8-message sequence,
  487. since an 8-message sequence will take 2 frames to send.
  488.  
  489.  
  490.  
  491.      Another way to look at it is:  When the last quarter frame message (F1
  492. 7X) arrives and the time can be fully assembled, the information is now
  493. actually 2 frames old.  A receiver of this time must keep an internal offset
  494. of +2 frames for displaying. This may seem unusual, but it is the way normal
  495. SMPTE is received and also makes backing up (running time code backwards) less
  496. confusing - when receiving the 8 quarter frame messages backwards, the F1 0X
  497. message still falls on the boundary of the frame it represents.
  498.  
  499.  
  500.  
  501.  
  502.  
  503.      Each quarter frame message number (0->7) indicates which of the 8 quarter
  504. frames of the 2-frame sequence we are on.  For example, message 0 (F1 0X)
  505. indicates quarter frame 0 of frame #1 in the sequence, and message 4 (F1 4X)
  506. indicates quarter frame 1 of frame #2 in the sequence.  If a reader receives
  507. these message numbers in descending sequence, then it knows that time code is
  508. being sent in the reverse direction.  Also, a reader can come on line at any
  509. time and know exactly where it is in relation to the 2-frame sequence, down to
  510. a quarter frame accuracy.
  511.  
  512.  
  513.  
  514.      It is the responsibility of the time code reader to insure that MTC is
  515. being properly interpreted.  This requires waiting a sufficient amount of time
  516. in order to achieve time code lock, and maintaining that lock until
  517. synchronization is dropped. Although each passing quarter frame message could
  518. be interpreted as a relative quarter frame count, the time code reader should
  519. always verify the actual complete time code after every 8-message sequence (2
  520. frames) in order to guarantee a proper lock.
  521.  
  522.  
  523.  
  524.      For example, let's assume the time is 01:37:52:16 (30 frames per second,
  525. non-drop).  Since the time is sent from least to most significant digit, the
  526. first two Quarter Frame messages will contain the data 16 (frames), the second
  527. two will contain the data 52 (seconds), the third two will represent 37
  528. (minutes), and the final two encode the 1 (hours and SMPTE Type).  The Quarter
  529. Frame Messages description defines how the binary data for each time field is
  530. spread across two nibbles. This scheme (as opposed to simple BCD) leaves some
  531. extra bits for encoding the SMPTE type (and for future use).
  532.  
  533.  
  534.  
  535.      Now, let's convert our example time of 01:37:52:16 into Quarter Frame
  536. format, putting in the correct hexadecimal conversions:
  537.  
  538.  
  539.  
  540.      F1 00
  541.  
  542.      F1 11     10H = 16 decimal
  543.  
  544.  
  545.  
  546.      F1 24
  547.  
  548.      F1 33     34H = 52 decimal
  549.  
  550.  
  551.  
  552.      F1 45
  553.  
  554.      F1 52     25H = 37 decimal
  555.  
  556.  
  557.  
  558.      F1 61
  559.  
  560.      F1 76     01H = 01 decimal (SMPTE Type is 30 frames/non-drop)
  561.  
  562.  
  563.  
  564.      (note:  the value transmitted is "6" because the SMPTE Type (11 binary) is
  565. encoded in bits 5 and 6)
  566.  
  567.  
  568.  
  569.      For SMPTE Types of 24, 30 drop frame, and 30 non-drop frame, the frame
  570. number will always be even.  For SMPTE Type of 25, the frame number may be
  571. even or odd, depending on which frame number the 8-message sequence had
  572. started.  In this case, you can see where the MIDI Time Code frame number
  573. would alternate between even and odd every second.
  574.  
  575.  
  576.  
  577.      MIDI Time Code will take a very small percentage of the MIDI bandwidth.
  578. The fastest SMPTE time rate is 30 frames per second.  The specification is to
  579. send 4 messages per frame - in other words, a 2-byte message (640
  580. microseconds) every 8.333 milliseconds.  This takes 7.68 % of the MIDI
  581. bandwidth - a reasonably small amount.  Also, in the typical MIDI Time Code
  582. systems we have imagined, it would be rare that normal MIDI and MIDI Time Code
  583. would share the same MIDI bus at the same time.
  584.  
  585.  
  586. Full Message
  587.  
  588.  
  589.  
  590.      Quarter Frame messages handle the basic running work of the system. But
  591. they are not suitable for use when equipment needs to be fast-forwarded or
  592. rewound, located or cued to a specific time, as sending them continuously at
  593. accelerated speeds would unnecessarily clog up or outrun the MIDI data lines.
  594. For these cases, Full Messages are used, which encode the complete time into a
  595. single message. After sending a Full Message, the time code generator can
  596. pause for any mechanical devices to shuttle (or "autolocate") to that point,
  597. and then resume running by sending quarter frame messages.
  598.  
  599.  
  600.  
  601. Full Message - (10 bytes)
  602.  
  603.  
  604.  
  605.      F0 7F <chan> 01 <sub-ID 2> hr mn sc fr F7
  606.  
  607.  
  608.  
  609.           F0 7F = Real Time Universal System Exclusive Header
  610.  
  611.           <chan> = 7F (message intended for entire system)
  612.  
  613.           01 = <sub-ID 1>, 'MIDI Time Code'
  614.  
  615.           <sub-ID 2> = 01, Full Time Code Message
  616.  
  617.           hr = hours and type: 0 yy zzzzz
  618.  
  619.                yy = type:
  620.  
  621.                     00 = 24 Frames/Second
  622.  
  623.                     01 = 25 Frames/Second
  624.  
  625.                     10 = 30 Frames/Second (drop frame)
  626.  
  627.                     11 = 30 Frames/Second (non-drop frame)
  628.  
  629.                zzzzz = Hours (00->23)
  630.  
  631.           mn = Minutes (00->59)
  632.  
  633.           sc = Seconds (00->59)
  634.  
  635.           fr = Frames (00->29)
  636.  
  637.           F7 = EOX
  638.  
  639.  
  640.  
  641.  
  642.  
  643.       Time is considered to be "running" upon receipt of the first Quarter
  644. Frame message after a Full Message.
  645.  
  646.  
  647. User Bits
  648.  
  649.  
  650.  
  651.      "User Bits" are 32 bits provided by SMPTE for special functions which
  652. vary with the application, and which can be programmed only from equipment
  653. especially designed for this purpose. Up to four characters or eight digits
  654. can be written. Examples of use are adding a date code or reel number to the
  655. tape.  The User Bits tend not to change throughout a run of time code.
  656.  
  657.  
  658.  
  659. User Bits Message - (15 bytes)
  660.  
  661.  
  662.  
  663.      F0 7F <chan> 01 <sub-ID 2> u1 u2 u3 u4 u5 u6 u7 u8 u9 F7
  664.  
  665.  
  666.  
  667.           F0 7F = Real Time Universal System Exclusive Header
  668.  
  669.           <chan> = 7F (message intended for entire system)
  670.  
  671.           01 = <sub-ID 1>, MIDI TIme Code
  672.  
  673.           <sub-id 2> = 02, User Bits Message
  674.  
  675.           u1 = 0000aaaa
  676.  
  677.           u2 = 0000bbbb
  678.  
  679.           u3 = 0000cccc
  680.  
  681.           u4 = 0000dddd
  682.  
  683.           u5 = 0000eeee
  684.  
  685.           u6 = 0000ffff
  686.  
  687.           u7 = 0000gggg
  688.  
  689.           u8 = 0000hhhh
  690.  
  691.           u9 = 000000ii
  692.  
  693.           F7 = EOX
  694.  
  695.  
  696.  
  697.      These nibble fields decode in an 8-bit format:  aaaabbbb ccccdddd
  698. eeeeffff gggghhhh ii.  It forms 4  8-bit characters,  and a 2 bit Format Code.
  699. u1 through u8 correspond to SMPTE Binary Groups 1 through 8.  u9 are the two
  700. Binary Group Flag Bits, as defined by SMPTE.
  701.  
  702.  
  703.  
  704.      This message can be sent whenever the User Bits values must be
  705. transferred to any devices down the line.  Note that the User Bits Message may
  706. be sent by the MIDI Time Code Converter at any time.  It is not sensitive to
  707. any mode.
  708.  
  709.  
  710.  
  711.  
  712.  
  713. MIDI Cueing
  714.  
  715.  
  716.  
  717.      MIDI Cueing uses Set-Up Messages to address individual units in a system.
  718. (A "unit" can be be a multitrack tape deck, a VTR, a special effects
  719. generator, MIDI sequencer, etc.)
  720.  
  721.  
  722.  
  723.      Of 128 possible event types, 19 are currently defined.
  724.  
  725.  
  726.  
  727.  
  728.  
  729. Set-Up Messages (13 bytes plus any additional information):
  730.  
  731.  
  732.  
  733.      F0 7E <chan> 04 <sub-ID 2> hr mn sc fr ff sl sm <add. info> F7
  734.  
  735.  
  736.  
  737.           F0 7E = Non-Real Time Universal System Exclusive Header
  738.  
  739.           <chan> = Channel number
  740.           04 = <sub-ID 1>, MIDI Time Code
  741.  
  742.           <sub-ID 2> = Set-Up Type
  743.                00 = Special
  744.                01 = Punch In points
  745.                02 = Punch Out points
  746.                03 = Delete Punch In point
  747.                04 = Delete Punch Out point
  748.                05 = Event Start points
  749.                06 = Event Stop points
  750.                07 = Event Start points with additional info.
  751.                08 = Event Stop points with additional info.
  752.                09 = Delete Event Start point
  753.                0A = Delete Event Stop point
  754.                0B = Cue points
  755.                0C = Cue points with additional info
  756.                0D = Delete Cue point
  757.                0E = Event Name in additional info
  758.  
  759.           hr = hours and type: 0 yy zzzzz
  760.  
  761.                yy = type:
  762.                     00 = 24 Frames/Second
  763.                     01 = 25 Frames/Second
  764.                     10 = 30 Frames/Second drop frame
  765.                     11 = 30 Frames/Second non-drop frame
  766.                zzzzz = Hours (00-23)
  767.  
  768.           mn = Minutes (00-59)
  769.  
  770.           sc = Seconds (00-59)
  771.  
  772.           fr = Frames (00-29)
  773.  
  774.           ff = Fractional Frames (00-99)
  775.  
  776.           sl, sm = Event Number (LSB first)
  777.  
  778.           <add. info.>
  779.  
  780.           F7 = EOX
  781.  
  782.  
  783. Description of Set-Up Types:
  784.  
  785.  
  786.  
  787.  
  788.  
  789.      00          Special refers to the set-up information that affects a unit
  790.                  globally (as opposed to individual tracks, sounds, programs,
  791.                  sequences, etc.). In this case, the Special Type takes the
  792.                  place of the Event Number. Five are defined.  Note that types
  793.                  01 00 through 04 00 ignore the event time field.
  794.  
  795.  
  796.  
  797.           00 00     Time Code Offset refers to a relative Time Code offset for
  798. each unit. For example, a piece of video and a piece of music that are
  799. supposed to go together may be created at different times, and more than
  800. likely have different absolute time code positions - therefore, one must be
  801. offset from the other so that they will match up. Just like there is one
  802. master time code for an entire system, each unit only
  803. needs one offset value per unit.
  804.  
  805.  
  806.  
  807.           01 00     Enable Event List means for a unit to enable execution of
  808. events in its list if the appropriate MTC or SMPTE time occurs.
  809.  
  810.  
  811.  
  812.           02 00     Disable Event List means for a unit to disable execution
  813. of its event list but not to erase it. This facilitates an MTC Event Manager
  814. in muting particular devices in order to concentrate on others in a complex
  815. system where many events occur simultaneously.
  816.  
  817.  
  818.  
  819.           03 00     Clear Event List means for a unit to erase its entire
  820. event list.
  821.  
  822.  
  823.  
  824.           04 00     System Stop refers to a time when the unit may shut down.
  825. This serves as a protection against Event Starts without matching Event Stops,
  826. tape machines running past the end of the reel, and so on.
  827.  
  828.  
  829.           05 00     Event List Request is sent by a master to an MTC
  830. peripheral. If the device ID (Channel Number) matches that of the peripheral,
  831. the peripheral responds by transmitting its entire cue list as a sequence of
  832. Set Up Messages, starting from the SMPTE time indicated in the Event List
  833. Request message.
  834.  
  835.  
  836.  
  837.      01/02     Punch In and Punch Out refer to the enabling and disabling of
  838. record mode on a unit. The Event Number refers to the track to be recorded.
  839. Multiple punch in/punch out points (and any of the other event types below)
  840. may be specified by sending multiple Set-Up messages with different times.
  841.  
  842.  
  843.  
  844.      03/04     Delete Punch In or Out deletes the matching point (time and
  845. event number) from the Cue List.
  846.  
  847.  
  848.  
  849.      05/06     Event Start and Stop refer to the running or playback of an
  850. event, and imply that a large sequence of events or a continuous event is to
  851. be started or stopped. The event number refers to which event on the targeted
  852. slave is to be played. A single event (ie. playback of a specific sample, a
  853. fader movement on an automated console, etc.) may occur several times
  854. throughout a given list of cues.  These events will be represented by the same
  855. event number, with different Start and Stop times.
  856.  
  857.  
  858.  
  859.      07/08     Event Start and Stop with Additional Information refer to an
  860. event (as above) with additional parameters transmitted in the Set Up message
  861. between the Time and EOX. The additional parameters may take the form of an
  862. effects unit's internal parameters, the volume level of a sound effect, etc.
  863. See below for a description of additional information.
  864.  
  865.  
  866.      09/0A     Delete Event Start/Stop means to delete the matching (event
  867. number and time) event (with or without additional information) from the Cue
  868. List.
  869.  
  870.  
  871.  
  872.      0B          Cue Point refers to individual event occurences, such as
  873. marking "hit" points for sound effects, reference points for editing, and so
  874. on.  Each Cue number may be assigned to a specific reaction, such as a
  875. specific one-shot sound event (as opposed to a continuous event, which is
  876. handled by Start/Stop).  A single cue may occur several times throughout a
  877. given list of cues.  These events will be represented by the same event
  878. number, with different Start and Stop times.
  879.  
  880.  
  881.  
  882.      0C          Cue Point with Additional Information is exactly like Event
  883. Start/Stop with Additional Information, except that the event represents a Cue
  884. Point rather than a Start/Stop Point.
  885.  
  886.  
  887.  
  888.      0D          Delete Cue Point means to Delete the matching (event number
  889. and time) Cue Event with or without additional information from the Cue List.
  890.  
  891.  
  892.  
  893.      0E          Event Name in Additional Information.  This merely assigns a
  894. name to a given event number.  It is for human logging purposes.  See
  895. Additional Information description.
  896.  
  897.  
  898.  
  899.  
  900.  
  901. Event Time
  902.  
  903.  
  904.  
  905.      This is the SMPTE/MIDI Time Code time at which the given event is
  906. supposed to occur.  Actual time is in 1/100th frame resoultion, for those
  907. units capable of handling bits or some other form of sub-frame resolution, and
  908. should otherwise be self-explanatory.
  909.  
  910.  
  911.  
  912. Event Number
  913.  
  914.  
  915.  
  916.      This is a fourteen-bit value, enabling 16,384 of each of the above types
  917. to be individually addressed. "sl" is the 7 LS bits, and "sm" is the 7 MS
  918. bits.
  919.  
  920.  
  921.  
  922. Additional Information description
  923.  
  924.  
  925.  
  926.      Additional information consists of a nibblized MIDI data stream, LS
  927. nibble first.  The exception is Set-Up Type OE, where the additional
  928. information is nibblized ASCII, LS nibble first.  An ASCII newline is
  929. accomplished by sending CR and LF in the ASCII. CR alone functions solely as a
  930. carriage return, and LF alone functions solely as a Line-Feed.
  931.  
  932.  
  933.  
  934.      For example, a MIDI Note On message such as 91 46 7F would be nibblized
  935. and sent as 01 09  06 04 0F 07.  In this way, any device can decode any
  936. message regardless of who it was intended for.  Device-specific messages
  937. should be sent as nibblized MIDI System Exclusive messages.
  938.  
  939.  
  940. Potential Problems
  941.  
  942.  
  943.  
  944.      There is a possible problem with MIDI merger boxes improperly handling
  945. the F1 message, since they do not currently know how many bytes  are
  946. following. However, in typical MIDI Time Code systems, we do not anticipate
  947. applications where the MIDI Time Code must be merged with other MIDI signals
  948. occuring at the same time.
  949.  
  950.  
  951.  
  952.      Please note that there is plenty of room for additional set-up types,
  953. etc., to cover unanticipated situations and configurations.
  954.  
  955.  
  956.  
  957.      It is recommended that each MTC peripheral power up with its MIDI
  958. Manufacturer's System Exclusive ID number as its default channel/device ID.
  959. Obviously, it would be preferable to allow the user to change this number from
  960. the device's front panel, so that several peripherals from the same
  961. manufacturer may have unique IDs within the same MTC system.
  962.  
  963.  
  964.  
  965.  
  966.  
  967. Signal Path Summary
  968.  
  969.  
  970.  
  971.      Data sent between the Master Time Code Source (which may be, for example,
  972. a Multitrack Tape Deck with a SMPTE Synchronizer) and the MIDI Time Code
  973. Converter is always SMPTE Time Code.
  974.  
  975.  
  976.  
  977.      Data sent from the MIDI Time Code Converter to the Master Control/Cue
  978. Sheet (note that this may be a MTC-equipped tape deck or mixing console as
  979. well as a cue-sheet) is always MIDI Time Code.  The specific MIDI Time Code
  980. messages which are used depend on the current operating mode, as explained
  981. below:
  982.  
  983.  
  984.       Play Mode:  The Master Time Code Source (tape deck) is in normal PLAY
  985.                   MODE at normal or vari-speed rates.  The MIDI Time Code
  986.                   Converter is transmitting Quarter Frame ("F1") messages to
  987.                   the Master Control/Cue Sheet.  The frame messages are in
  988.                   ASCENDING order, starting with "F1 0X" and ending with "F1
  989.                   7X". If the tape machine is capable of play mode in REVERSE,
  990.                   then the frame messages will be transmitted in REVERSE
  991.                   sequence, starting with "F1 7X" and ending with "F1 0X".
  992.  
  993.  
  994.  
  995.       Cue Mode:   The Master Time Code Source is being "rocked", or "cued" by
  996.                   hand.  The  tape is still contacting the playback head so
  997.                   that the listener can cue, or preview the    contents of the
  998.                   tape slowly. The MIDI Time Code Converter is transmitting
  999.                   FRAME ("F1") messages to the Master Control/Cue Sheet.  If
  1000.                   the tape is being played in the FORWARD direction, the frame
  1001.                   messages are sent in ASCENDING order, starting with "F1 0X"
  1002.                   and ending with "F1 7X". If the tape machine is played in
  1003.                   the REVERSE direction, then the frame messages will be
  1004.                   transmitted in REVERSE sequence, starting with "F1 7X" and
  1005.                   ending with "F1 0X".
  1006.  
  1007.  
  1008.  
  1009.                   Because the tape is being moved by hand in Cue Mode, the
  1010.                   tape direction can change quickly and often.  The order of
  1011.                   the Frame Message sequence must change along with the tape
  1012.                   direction.
  1013.  
  1014.  
  1015.  
  1016.        Fast-Forward/Rewind Mode:  In this mode, the tape is in a
  1017.                   high-speed wind or  rewind, and is not touching the playback
  1018.                   head.  No "cueing" of the taped material is going on.  Since
  1019.                   this is a "search" mode, synchronization of the Master
  1020.                   Control/Cue Sheet is not as important as in the Play or Cue
  1021.                   Mode.  Thus, in this mode, the MIDI Time Code Converter only
  1022.                   needs to send a "Full Message" every so often to the Cue
  1023.                   Sheet.  This acts as a rough indicator of the Master's
  1024.                   position.  The SMPTE time indicated by the "Full Message"
  1025.                   actually takes effect upon the reception of the next "F1"
  1026.                   quarter frame message (when "Play Mode" has resumed).
  1027.  
  1028.  
  1029.  
  1030.       Shuttle Mode:  This is just another expression for "Fast-Forward/Rewind
  1031.                   Mode".
  1032.  
  1033.  
  1034.  
  1035.  
  1036.  
  1037.  
  1038. References and Credits
  1039.  
  1040.  
  1041.  
  1042.      SMPTE 12M (ANSI V98.12M-1981).
  1043.  
  1044.  
  1045.  
  1046.      MIDI Time Code specification created by Chris Meyer and Evan Brooks of
  1047. Digidesign. Thanks to Stanley Jungleib of Sequential for additional text.
  1048. Also many thanks to all of the MMA and JMSC members for their suggestions and
  1049. contributions to the spec.
  1050.